(レポート) Developers Summit 2015 Autumn S-5:データファースト開発 #devsumi

本記事はDevelopers Summit 2015 AutumnのS-5セッション、「データファースト開発 -開発チームのためのデータ分析環境の構築と継続的改善の仕組み-」のレポートです。

レポート

データファースト開発 -開発チームのためのデータ分析環境の構築と継続的改善の仕組み- by 株式会社サイバーエージェント 神田 勝規氏

・システム開発している普通のエンジニアが、どうやってシステムサイクルの中にデータを取り込んでいくのか？ ・システム改善のサイクル。現状を把握し、改善案を作って、実際に設計したり実装して、また現状を把握する。 ・今日話すのは現状把握。データを分析して、システムに何が起きているのかを理解して、サイクルに繋げていく。

・普通のエンジニアである僕がどうしてデータに興味を持ったのか？ ・現状把握に何分かかるか？という課題があった ・システム運用の中で当然知っておかなければいけないこと、基本的な情報。定型的な分析であれば即時できる。 ・アドホックな条件を加えて分析をしようとすると、ものによっては1週間以上かかる場合もあった。 ・これってどうなってるんだろう、という単純な疑問なのに、解決するのに時間がかかりすぎる。 ・分析の前準備に時間がかかる→本当に困るまで調査しなくなってしまう。 ・そうすると、きっとそうだろう、という根拠のない思い込みや、日々状況が変わっているのに古い調査結果を見て、謝った判断をしてしまう。 ・データを取り出すことはやり方さえ知っていれば誰でもできるはずなのに、時間がかかることによって、データを見ることが特異なスキルが必要なんだと思われる。 ・結果、一連のフローがだんだん属人化してしまう。

・どの工程に時間がかかっていたのか ・データを分析しようとしたときに、どんなデータが必要なのかを選定、ETL処理し、抽出し、分析。 ・データが大きいとETL処理、抽出処理で時間がかかる。 ・データを選定の仕方、絞り方で全体の工程の時間が変わってくる。

・理想は、誰でも気軽に、ふとした疑問に対して答えられるような状況が理想。 ・理想に向けて必要なこと。 ・データへアクセスが容易なこと、極力広い範囲の人たちがデータにアクセスできたほうが開発の改善になる。 ・高い応答性。理想的には5分以内くらいでデータが返るように。 ・手順の再現性。誰がやっても同じ結果が得られる。

・データ分析の専用のログを出力 ・アプリケーションの汎用的なログではなく、分析基盤に乗せられるような、分析用のログを作った。 ・データのサイズを抑えたり、分析にかかる時間を短縮化することができる。 ・作った分析用ログを分析するための基盤。 ・BigQuery + オンプレSpark。 ・BigQueryを使っているのでストレージはGoogle Cloud Storage。 ・UIはApache ZeppelinとJupyter。 ・2つ使っているのはユーザーのニーズ。それぞれ使いたいという人がいる。 ・データ分析基盤の全体像。 ・アプリケーションサーバのログをfluentdでBigQueryに流し込む。 ・BigQueryから一定時間経ったデータをGoogle Cloud StorageにExport。 ・オンプレのSparkではいろんなデータソースの分析を行っている。

・どうしてこの構成になったのか？ ・応答性を重視。BigQueryではIndex的なものが不要、アドホックな分析に向いている。 ・コストも人が行う分にはそんなにかからない。時間がかかるクエリにはアドバイスももらえる。 ・用途によって環境を使い分ける。機械学習を使ってモデルやクラスタリングをする場合にはオンプレのSpark。 ・応答性を重視する理由 ・フィーリングは重要。根拠がない直感はダメだけど、直感は案外正しい。直感の根拠を見つける。 ・直感に合うようなデータを探すようにならないように、多方面から調べられることは重要。 ・結果を得られるのに時間がかかると、調査に対するコストと得られるメリットのバランスを考えて、ちょっと調べたい、みたいなことができない。 ・遊びの調査も5分で得られるのであれば、やってみることが出来る。 ・思いついてからトータルで10分以内で見れるのであれば、フィーリングで調査が出来るようになる。 ・遊びのある調査から新しい発見、気づきがある。

・データ分析基盤→あんまり使われない ・なぜ使われなかったのか？使い方がわからない、何に使えるのかがわからない。 ・開発チームが分析の基盤を持っても、そもそも何するんだっけ？となった ・使い方の共有。チュートリアル、ドキュメント化、ノートブックを活用。 ・ZeppelinとJupyterでは他の人が分析した手順が実行できる形式で残る。 ・0から作るのは大変だけど、他人が作ったのを改造して使うのは楽。 ・Zeppelinのデモ。Tutorial。ノートブックの言語はScala。CSVファイルを取得、SplitしてFilter、Spark SQLが使えるようにデータを処理。 ・何に使えるのか、の共有。結構大変で今も試行錯誤。分析前の基礎集計の結果と手順を共有。必要なものは定型ジョブ化。Tableauなどを使って可視化。 ・可視化から不具合を発見して改修したケースもある。

・エンジニアはデータ分析基盤を何に使うのか？ ・開発する根拠を発見。リリースした後の効果、改善を客観的に評価。 ・これからの課題→ワークフローの整備などが必要。

・まとめ ・BigQueryと出会って人生が変わった ・自分たちのシステムをより深く理解することが出来るようになった ・データ分析基盤を自分たちが理解することで、自分たちの行動、開発した機能を評価できる ・BigQueryを使おうと思えばすぐ使える状況になっている ・データを見れない、見ていないということはもはやリスク